* It'd be nice to have some example output somewhere.  Docs on tracing Nexus would be nice but would be much more work.  Maybe just drop some example output in the D script itself?

Will do.

* For authn, I imagine we might want to know what actor tried to (or did) authenticate.  We might already have this in the result? (sample output would show).  I'm torn about whether we'd also want to provide the token that's being authenticated.  Since it's sensitive (so there's downside to including it), it's probably not worth including until/unless we have a use case.

The authentication result does already contain the actor, if the authentication was successful. If the authentication failed, we include the reason. That sometimes includes the actor, but not always. Is that enough, or should we modify things to always include the actor (or attempted actor)?

* If we have other "nexus" provider probes, do these just show up alongside all of those?  So that as far as consumers are concerned, they just see one "Nexus" provider with these probes and the other ones?  That seems ideal but I didn't realize that was possible.

That's right. You can rename the provider using #[usdt::provider(provider = "foo")], and anything named that way is in the same provider (assuming they're in the same process).

The authentication result does already contain the actor, if the authentication was successful. If the authentication failed, we include the reason. That sometimes includes the actor, but not always. Is that enough, or should we modify things to always include the actor (or attempted actor)?

That's great. If we need more, we can always iterate.

I've added example output to both D scripts in a68d33e

Thanks! That output helps me realize: we're really going to want the request id here, aren't we? I'm imagining the major use cases for this are going to involve correlating authn/authz activity with specific requests. Is that easy to plumb through?

We can include that pretty easily for the authn probes, but the authz probes are more difficult. Those might not even have a request ID, such as during sagas or background tasks. We could include it when we have it, and some other, random-ish string when we don't?

Yeah, that makes sense. Maybe NULL if there is none?

Yeah, that could work. This is a bigger change, but we might consider putting the request ID into the OpContext if we have one. I was actually surprised to see that it's not there already! For example, the OpKind::{ExternalApiRequest,InternalApiRequest} could store that internally.

The main justification for this is that almost every authz check calls OpContext::authorize(), which only takes the action and resource. Modifying this interface to include a request ID seems pretty annoying. Most call sites don't have that information, since they're buried in places like sagas or the datastore internals. Instead, we could attach it to the OpContext when we create one for an API request, and then emit it in the probes as needed.

Yeah, that could work. This is a bigger change, but we might consider putting the request ID into the OpContext if we have one. I was actually surprised to see that it's not there already! For example, the OpKind::{ExternalApiRequest,InternalApiRequest} could store that internally.

I'm also surprised it's not already there! I agree it should be -- that's exactly the sort of thing that's intended to be there, and exactly for reasons like this.

Agreed. I'm going to put that up in a separate PR, and then merge or rebase this on top of that.

I've added the request ID where possible in 6cfdd3d